那么，就有几个问题：

下面就稍微梳理下

需要注意的是，N是最大并行数，而不是“X核CPU”的X。 一般我们会听到例如“4核8线程”的说法，这里的8就是N，虽然只有4个CPU（核心），但是可以利用超线程技术把原来CPU4个线程虚拟成8个。

会返回计算机的最大并行数

首先要明确，2N跟N+1都是经验值，大家能明白大概的逻辑就行

这个有一个公式：

理想线程数=最大并行数*期望CPU利用率*(CPU计算时间+等待时间)/CPU计算时间

下面我们试图理解一下。首先先明公式里几个变量的意义：

首先要明确，在涉及大量数据IO的场景下，CPU利用率最高的时候是什么时候？肯定是当任务A在等待IO时，CPU可以切到任务B进行CPU运算，保证CPU不会因为等待IO而停下来。

因此会有 最大并行数*(CPU计算时间+等待时间)/CPU计算时间 如果理想地认为CPU计算时间等于等待时间，那么就是2N了。

当然大部分场景下这是不可能的，一般Web项目中IO时间，也就是上面说的CPU等待时间，都远高于CPU处理时间（因此MySQL才会用B+树做索引来减小每查找一层增加的IO）。比如一个简单的数据库查询，计算可能只有0.1ms，IO则可能达到2ms，这样一算，得21N了。所以2N只是个理想的经验值，在高IO时间开销的场景，可以是10N、20N、30N等等。

回到我们的出发点：希望CPU一刻不停的工作。 CPU密集型运算场景下，我们就不再考虑IO了。这时候CPU空闲的原因一般就是正在处理的任务出现错误，暂停了。这个时候如果我们有另一个任务恰好补上来，那CPU就没得歇了。所以是N+1。当然这也是经验值。

网上也有说法是，CPU密集型运算的最大线程数可以设置在N~2N，这个也不难理解，如果我们N个实际线程都在处理任务，他们发生了错误，每个都有个替补的补上，这就是2N了。

但1.5N或者2N之类比较大的线程数也不一定是最好的，前面的一切分析都是基于“提高CPU利用率”这个目的，但是不一定代表速度就快，对于任务失败可能性比较低的场景，设2N属于纯粹没事找事，因为并不需要这么多候补的任务，多出来的一起排队反而是给缓存上强度，上下文切换的时候开销更大了（大概）。之前由朋友做课程实验，是起多个线程并行做矩阵运算，发现其实N是最快的，因为矩阵运算失败可能性很小。

https://blog.csdn.net/Cover_sky/article/details/121371973 https://cloud.tencent.com/developer/article/1730603